Reconstruct drive for dynamic resizing

ABSTRACT

A solid-state drive (SSD) is configured for dynamic resizing. When the SSD approaches the end of its useful life because the over-provisioning amount is nearing the minimum threshold as a result of an increasing number of bad blocks, the SSD is reformatted with a reduced logical capacity so that the over-provisioning amount may be maintained above the minimum threshold.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a divisional of U.S. patent application Ser. No.15/699,972, filed on Sep. 8, 2017, which is a continuation of U.S.patent application Ser. No. 14/526,424, filed on Oct. 28, 2014, now U.S.Pat. No. 9,760,482, issued Sep. 12, 2017, the entire contents of whichare incorporated herein by reference.

BACKGROUND

Recently, solid state drives (SSDs) have been adopted widely as itprovides lower latency input-output operations (IOs) than rotating diskbased drives. However, the acquisition costs of SSDs are comparativelyhigher, and the performance of SSDs degrades as the number of bad blocksin the SSDs increases over time. As a buffer against bad blocks thatincrease over time and to also provide a storage area that can be usedfor garbage collection and other system functions, SSDs are typicallyover-provisioned by a set amount. To give an example, an SSD that has alogical capacity of 100 GB, i.e., the capacity that is exposed as beingusable capacity, may be initially over-provisioned by a predeterminedamount, e.g., 20 GB. This predetermined amount is set to be larger thana minimum amount that is needed for functions such as garbage collectionso that the SSD will not fail as long as the number of bad blocks remainbelow a certain limit. It should be recognized that the larger thispredetermined over-provisioning amount becomes, the longer the usefullife of the SSD will be. In addition, a larger over-provisioning amountimproves the IOPS (IOs per second) performance of the SSD. However, theover-provisioning amount should not be set too large because it takesaway from the useful capacity of the SSD.

SUMMARY

Embodiments provide an SSD that is configured for dynamic resizing.According to embodiments, when the SSD approaches the end of its usefullife because the over-provisioning amount is nearing the minimumthreshold as a result of an increasing number of bad blocks, the SSD isreformatted with a reduced logical capacity so that theover-provisioning amount may be maintained above the minimum threshold.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drive connected to a host in which embodiments may bepracticed.

FIG. 2 illustrates changes to a drive's over-provisioning percentage andlogical capacity over time when embodiments are implemented.

FIG. 3 illustrates one example of a CDB for a first API employed in themethod according to embodiments.

FIG. 4 graphically illustrates how much of the user data can bepreserved while performing dynamic resizing according to embodiments.

FIG. 5 illustrates a communication flow between the host and the driveupon issuance of a second API employed in the method according toembodiments.

FIG. 6 illustrates an example data format for over-provisioninginformation that is returned from the drive to the host.

FIG. 7 is a flow diagram of steps carried out by the host and the driveduring dynamic resizing according to embodiments.

FIG. 8 illustrates graphically a situation where a currentover-provisioning amount is not sufficient.

FIG. 9 illustrates graphically an example where an over-provisioningamount is specified in the first API.

DETAILED DESCRIPTION

FIG. 1 is a drive (e.g., an SSD) 100 connected to a host 10 in whichembodiments may be practiced. Host 10 is a computing device that issuesIOs to drive 100 through standard storage interfaces such as iSCSI,SATA, PCIe, SAS, etc. and includes conventional components of a computersuch as one or more processors, random access memory, a networkinterface, and a disk interface. In the embodiments illustrated herein,host 10 is further configured with a drive reconstruct software module20 that resides in memory and executes on the processors to reconfiguredrive 100 according to the method described below in conjunction withFIG. 7.

Drive 100 includes an interface 110, e.g., an iSCSI interface, a SATAinterface, a PCIe interface, or a SAS interface, a drive controller 120,a random access memory (RAM) 130, a high-speed data path 140, which maybe any high-speed bus known in the art, such as a double data rate (DDR)bus, a DDR2 bus, a DDR3 bus, or the like, and a flash memory device 150.Drive controller 120 is configured to control the operation of drive100, and is connected to RAM 130 and flash memory device 150 viahigh-speed data path 140. Drive controller 120 is also configured tocontrol interface 110. Some or all of the functionality of drivecontroller 120 may be implemented as firmware, application-specificintegrated circuits, and/or a software application. RAM 130 is avolatile semiconductor memory device, such as a dynamic RAM (DRAM). RAM130 is configured for use as a data buffer for SSD 140, temporarilystoring data received from host 10.

In addition, drive controller 120 maintains a bad block map 135 in RAM130. Bad block map 135 includes addresses of blocks in flash memorydevice 150 that have been determined by driver controller 120 to be bad.Drive controller 120 may make this determination during reads and writesperformed on blocks of flash memory device 150, or during a partial orfull scan for bad blocks performed on blocks of flash memory device 150.

Flash memory device 150 is a non-volatile semiconductor storage, such asa NAND flash chip, that can be electrically erased and reprogrammed. Forclarity, drive 100 is illustrated in FIG. 1 to include a single flashmemory device 150, but in many embodiments, drive 100 includes multipleflash memory devices 150. Flash memory device 150 includes a pluralityof memory cells that are grouped into readable and writable pages, eachpage having a size of 4 KB to 16 KB. These pages are organized intomemory blocks (typically 128 to 512 pages per block), the memory blockrepresenting the smallest erasable unit of flash memory device 150.

Flash memory device 150 has an associated raw physical capacity. Duringa drive initialization process known as formatting, drive controller 120configures flash memory device 150 with a logical capacity that is equalto the raw physical capacity minus a system area amount (typically afixed amount) and a predetermined over-provisioning amount, which asdescribed above is used as a buffer against bad blocks that increaseover time and to also provide a storage area that can be used forgarbage collection and other system functions. FIG. 2 shows therelationship between the over-provisioned amount and the logicalcapacity of drive 100. At time t0, when there are no bad blocks, theover-provisioned amount is at its predetermined level. However, as thenumber of bad blocks begins to increase at time t1, the over-provisionedamount begins to decrease. At time t2, the over-provisioned amountreaches a minimum threshold, and drive 100 is dynamically resizedaccording to techniques described below. As a result of the dynamicresizing, the logical capacity decreases and the over-provisioned amountincreases to the predetermined level.

To support dynamic resizing, drive 100 is configured with twoapplication programming interfaces (APIs) that are exposed to host 10.The first is the Reconstruct API, which has a single input parameter ortwo input parameters. One example of the Reconstruct API has a commanddescriptor block (CDB) shown in FIG. 3. If the first input parameter is0, drive controller 120 executes the dynamic resizing without scanningflash memory device 150 for bad blocks. If the first input parameter is1, drive controller 120 executes the dynamic resizing after a partialscan of flash memory device 150 for bad blocks. If the first inputparameter is 2, drive controller 120 executes the dynamic resizing aftera full scan of flash memory device 150 for bad blocks. Optionally, thepredetermined over-provisioning amount may be overridden by the secondinput parameter when the second input parameter has a non-zero value.Upon receiving the Reconstruct API from host 10, driver controller 120returns an acknowledgement of receipt to host 10 and executes theprocess for dynamic resizing as described below in conjunction with FIG.7. Other features of the Reconstruct API are as follows. User data islost when this API is executed. Alternatively, the user data up to theamount of the resized logical capacity may be preserved as shown in FIG.4. In addition, after the acknowledgement of this API, host 10 may notbe able to detect drive 100 and commands from host 10 are not guaranteedto be executed.

The second API is the Get_Overprovisioning_Information API. This API hasno input parameters. The communication flow between host 10 and drivecontroller 120 upon issuance of this API by host 10 is schematicallyillustrated in FIG. 5. Upon receiving theGet_Overprovisioning_Information API from host 10, driver controller 120reads the predetermined over-provisioning amount and the minimumover-provisioning amount for normal operation from drive metadata storedin RAM 130 and/or flash memory device 150, and also computes the currentover-provisioning amount according to the formula: currentover-provisioning amount=raw physical capacity−current logicalcapacity−bad block capacity−system area amount. Then, driver controller120 returns status (PASS or FAIL) to host 10 as an acknowledgement andthereafter returns the predetermined over-provisioning amount and theminimum over-provisioning amount to host 10 as over-provisioninginformation. One example data format for the predeterminedover-provisioning amount and the minimum over-provisioning amount isillustrated in FIG. 6.

FIG. 7 is a flow diagram of steps carried out by host 10 and drive 100during dynamic resizing according to embodiments. Steps 710, 720, 730,740, and 790 are carried out by host 10 through drive reconstructsoftware module 20. Steps 715, 745, 750, 760, 770, and 780 are carriedout by drive 100, in particular drive controller 120. Although the stepsof FIG. 7 are described herein as performed by host 10 and drive 100, itshould be recognized that other systems, such as integrated host-drivesystems, may implement the steps of FIG. 7.

The method of FIG. 7 begins at step 710 where host 10 issues theGet_Overprovisioning_Information API to drive 100. This step may beexecuted once every hour, after a predetermined size of data has beenwritten, after a predetermined percentage of the logical capacity iswritten, when drive 100 becomes idle, or when drive 100 is powered up.As a result, host 10 can recognize that drive 100 is approachingend-of-life in advance and can dynamically resize the logical capacityof drive 100 before drive 100 fails. Upon receipt ofGet_Overprovisioning_Information API from host 10, drive controller 120at step 715 reads the predetermined over-provisioning amount and theminimum over-provisioning amount for normal operation from drivemetadata stored in RAM 170 and/or flash memory device 150, and alsocomputes the current over-provisioning amount according to the formula:current over-provisioning amount=raw physical capacity−current logicalcapacity−bad block capacity. The bad block capacity is determined basedon the information stored in bad block map 135. For example, if badblock map 135 indicates 100 blocks as being bad blocks and each block is512 KB in size, the bad block capacity will be 5.12 MB.

At step 720, host 10 receives the over-provisioning informationincluding the predetermined over-provisioning amount, the minimumover-provisioning amount, and the current over-provisioning amount fromdrive 100. Based on this, at step 730, host 10 determines if the currentover-provisioning amount is sufficient, e.g., greater than the minimumover-provisioning amount. FIG. 8 illustrates graphically a situationwhere the current over-provisioning amount is not sufficient. When host10 determines that the current over-provisioning amount is sufficient,the execution flow returns to step 710 where host 10 issues theGet_Overprovisioning_Information API to drive 100 at the start of thenext period. On the other hand, when host 10 determines that the currentover-provisioning amount is not sufficient, host 10 at step 740 issuesthe Reconstruct API to drive 100. As explained above, the ReconstructAPI may be issued with an input parameter of 0, 1, or 2.

Upon receipt of the Reconstruct API, at step 745, drive controller 120returns an acknowledgement of receipt to host 10 (not shown) anddetermines if scanning of flash memory device 150 for bad blocks isneeded according to the value of the input parameter included in theReconstruct API. If the input parameter is 0, drive controller 120proceeds to step 760 without scanning. If the input parameter is 1 or 2,drive controller 120 scans flash memory device 150 for bad blocks andupdates bad block map 135 accordingly. If the input parameter is 1,drive controller 120 performs partial scanning for bad blocks and, ifthe input parameter is 2, drive controller 120 performs full scanningfor bad blocks. During the partial or full scan for bad blocks, drivecontroller 120 updates bad block map 135 to include bad blocks that arediscovered as a result of the scanning. The partial or full scan includea self-test comprising block erase tests, page program tests and/or pageread tests. When an erase failure, a program failure, or anuncorrectable ECC failure occurs during the partial or full scan, ablock in which the failure happens is determined as a bad block.

At step 760, driver controller 120 computes a target logical capacityfor flash memory device 150. The target logical capacity is computedaccording to the formula: target logical capacity=raw physicalcapacity−predetermined over-provisioning amount−bad blockcapacity−system area amount. The bad block capacity is determined basedon the information stored in bad block map 135 as described above inconjunction with step 715.

If the predetermined over-provisioning amount is overridden by thesecond input parameter of the Reconstruct API, the target logicalcapacity is computed according to the formula: target logicalcapacity=raw physical capacity−overridden over-provisioning amount−badblock capacity−system area amount. FIG. 9 illustrates graphically anexample where the second input parameter of the Reconstruct API wasgiven a value greater than the predetermined over-provisioning amount.

After the target logical capacity is computed at step 760, drivercontroller 120 at step 770 carries out the reformatting of flash memorydevice 150 according to known techniques so that the resulting logicalcapacity after the reformatting is equal to the target logical capacity.It should be recognized that during this reformatting, user data storedin flash memory device 150 will be lost. In addition, host 10 will notbe able to detect drive 100 and commands from host 10 will not beacknowledged.

Upon completion of the reformatting and as acknowledgement of successfulcompletion, driver controller 120 at step 380 returns the target logicalcapacity to host 10. Upon receipt of the target logical capacity at step390, host 10 recognizes that normal IO operation of drive 100 is resumedand resumes periodic polling for over-provisioning information at step310.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof, and the scope thereof isdetermined by the claims that follow.

What is claimed is:
 1. A storage device comprising: a non-volatilesemiconductor memory having a raw physical capacity equal to a firstsize; and a controller configured to over-provision the non-volatilesemiconductor memory by a predetermined amount, to track bad blocks inthe non-volatile semiconductor memory, and to format the non-volatilesemiconductor memory to reduce a logical capacity thereof to a secondsize in response to a command from a host, wherein the second size isequal to the first size minus: (i) a third size corresponding to thepredetermined amount and (ii) a total size of the bad blocks.
 2. Thestorage device of claim 1, wherein the command from the host includes aparameter that can be set to one of multiple values, the value of theparameter determining whether or not the controller is to carry out ascan for bad blocks prior to reducing the logical capacity thereof. 3.The storage device of claim 2, wherein the controller does not carry outa scan for bad blocks if the parameter is set to a first value, carriesout a partial scan for bad blocks if the parameter is set to a secondvalue, and carries out a complete scan for bad blocks if the parameteris set to a third value.
 4. The storage device of claim 3, furthercomprising a volatile memory in which a map that tracks the bad blocksis maintained.
 5. The storage device of claim 4, wherein the controllerupdates the map when carrying out the partial scan or the complete scanfor bad blocks or when an erase, a read or a write operation performedon a block of the non-volatile semiconductor memory fails.
 6. Thestorage device of claim 1, wherein the predetermined amount is specifiedin the command from the host.
 7. The storage device of claim 1, whereinthe controller is configured to respond to a query from the host for avalue representing extra usable capacity with a value that is equal tothe first size minus: (i) a size corresponding to a current logicalcapacity of the non-volatile semiconductor memory and (ii) the totalsize of the bad blocks.
 8. A method of controlling a storage deviceincluding a non-volatile semiconductor memory that has a raw physicalcapacity equal to a first size and is formatted to have a logicalcapacity equal to a second size, an over-provisioned amount, and asystem area amount, the method comprising: receiving a command from ahost to reformat the non-volatile semiconductor memory; determining atarget logical capacity of the non-volatile semiconductor memory equalto a fifth size, the fifth size equal to the first size minus: (i) athird size corresponding to the predetermined amount ofover-provisioning, (ii) a fourth size corresponding to the predeterminedamount of the system area, and (iii) a total size of bad blocks of thenon-volatile semiconductor memory; and formatting the non-volatilesemiconductor memory to have the target logical capacity.
 9. The methodof claim 8, wherein the command from the host includes a parameter thatcan be set to one of multiple values, the value of the parameterdetermining whether or not the controller is to carry out a scan for badblocks prior to said formatting.
 10. The method of claim 9, furthercomprising: maintaining a map to track the bad blocks of thenon-volatile semiconductor memory, wherein the target logical capacityof the non-volatile semiconductor memory is determined using the mapwithout scanning if the parameter is set to a first value, with apartial scan for bad blocks if the parameter is set to a second value,and with a complete scan for bad blocks if the parameter is set to athird value.
 11. The method of claim 10, further comprising: updatingthe map when carrying out the partial scan or the complete scan for badblocks or when an erase, a read, or a write operation performed on ablock of the non-volatile semiconductor memory fails.
 12. The method ofclaim 8, wherein the third size is specified in the command from thehost.
 13. The method of claim 8, further comprising: responding to aquery from the host for a value representing extra usable capacity witha value that is equal to the first size minus: (i) a size correspondingto a current logical capacity of the non-volatile semiconductor memory,(ii) the fourth size, and (iii) the total size of the bad blocks. 14.The method of claim 8, wherein the fifth size is less than the secondsize.